home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 865 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.5 KB  |  82 lines

  1. Path: chronicle.mti.sgi.com!austern
  2. From: James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Quick questions
  5. Date: 26 Mar 1996 10:39:26 PST
  6. Organization: -
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <9603261132.AA22404@lts.sel.alcatel.de>
  9. References: <4j5b26$1e7a@mule1.mindspring.com>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: Tue, 26 Mar 96 12:32:46 +0100
  12. In-Reply-To: abell@mindspring.com's message of 25 Mar 1996 10:07:29 PST
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMVg6NEy4NqrwXLNJAQEYrwH/eOTxxSxe9uJaXYNs+9wSwAQzjFNQyWGS
  15.     NOweea4hAJMZProe4UOBjYIGTxIpOrSipDtzH2PVF5REQXIOmgipEQ==
  16.     =a7AC
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. In article <4j5b26$1e7a@mule1.mindspring.com> abell@mindspring.com
  20. (Andrew Bell) writes:
  21.  
  22. |> Hopefully these will have short answers, and aren't inappropriate for
  23. |> the newsgroup.
  24.  
  25. |> 1) Is there any way to catch an exception thrown in the constructor of
  26. |> a statically constructed object?  Does it call unexpected() or
  27. |> terminate() even?
  28.  
  29. Exactly.  There is no way to catch the exception, so terminate will be
  30. called.
  31.  
  32. |> 2) From a previous post on this group, it looks like the standard will
  33. |> allow one to define conversion operators for pre-existing, source code
  34. |> untouchable data types.  Yes? No? What will this look like? I have the
  35. |> May copy of the WP, and don't see any mention of this.
  36.  
  37. I'm not sure what you mean here.  You have always been able to define
  38. conversion operators for pre-existing types to *NEW* types; such
  39. operators are called constructors:-).  If you mean somehow change the
  40. meaning of e.g.: int->long, then I don't think that there is the
  41. slightest chance of this being supported.
  42.  
  43. |> 3) I often write what I call "pure wrapper" classes to give access
  44. |> protection and data abstraction to pre-existing data types.  A pure
  45. |> wrapper class is a class that adds no member variables or virtual
  46. |> member functions to a class/struct that has no virtual functions of
  47. |> its own, so their size and alignment should be the same and casting
  48. |> between the two should be perfectly safe.  The new standard doesn't
  49. |> have any special support (for example, allowing it automatically) for
  50. |> this, does it?
  51.  
  52. I'd like something like this too.  I often derive for the sole purpose
  53. of changing the default constructor.
  54.  
  55. The only place where this is really an issue, however, is in arrays.
  56. And since vector uses the copy constructor (rather than the default
  57. constructor) to initialize, IMHO, it is no longer an issue there,
  58. either. 
  59.  
  60. So while some added guarantees might be nice, they really aren't worth
  61. the effort it would take to define them.
  62.  
  63. |> 4) With RTTI, a derived class that doesn't change any virtual member
  64. |> funcs or add any properties to a base class still evaluates to a
  65. |> different object type, correct?
  66.  
  67. One would certainly hope so.  I cannot think of any reason why it would
  68. be different.
  69.  
  70. --
  71. James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
  72. GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
  73. Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
  74.                 -- A la recherche d'une activitΘ dans une region francophone
  75. ---
  76. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  77.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  78.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  79.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  80.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  81. ]
  82.